A Parallel Logic Programming Language for PEPSys

This paper describes a new parallel Logic Programming language designed to exploit the ORand Independent ANDparallelisms. The language is based on conventional Prolog but with natural extensions to support handling of multiple solutions and expression of parallelism. 1 . I n t r o d u c t i o n PEPSys (Parallel ECRC Prolog System) is a research project started in mid 1984 in the Computer Architecture Group of the European * Computer-industry Research Centre (ECRC). Its general goals are to study and evaluate new and practicable solutions to the problems of parallel logic programming. Although the project aims at investigating parallel computer architectures for logic programming, it began with an attempt to define the application programmer's needs [Ratcliffe and Robert, 1985], as well as a study of existing parallel logic models [Syre and Westphal, 1985). These considerations led us to define a high level language for parallel logic programming, which offers facilities for sequential programming, as in conventional Prolog, as well as others allowing the expression of AND-parallelism, ORparallelism, controlled by the programmer. Beside the language definition, we have also defined) a parallel computational model, and we are currently writing a compiler for the language generating a parallel intermediate-level language. This will be used for an implementation of PEPSys on a commercial multiprocessor system. Simultaneously, we are studying parallel computer architectures adapted to our approach. These will be evaluated by simulation. This paper focuses on the PEPSys high level language |Ratcliffe and Robert, 1986] Section 2 presents the objectives of the language and compares them with other approaches. Section 3 describes the main characteristics of the language, and an example showing its main features. Section 4 gives results obtained by a high level interpretation of the language, combined with an evaluation of the execution of some application programs. Section 5 discusses the useful extensions that are felt important but kept aside for further study. Section 6 presents the current status of the activities in the PEPSys project. In addition to the writers of this paper, the co-authors of the work pre*ented here are Max Hailperin, Philippe Robert, and Harald Westphal. The PEPSys project team includes also Uri Baron, Jacques Chassin de Kergommeaux, Bounthara lng, and Donald Peterson, all full time researchers at ECRC, most of whom have contributed to the definition of the language by their comments or the use of it. iffe and Jean-Claude Syre , 8000 Muenchen 81, West Germany 2 . O b j e c t i v e s o f t h e L a n g u a g e In order to present the objectives of PEPSys, we would first like to situate our approach among the numerous proposals under study for parallel logic languages. Due to lack of space, we will restrict our short review to the most characteristic works. More on the subject can be found in [Syre and Westphal, 1985] [Gregory, 1986] [Crammond, 1985] 2 . 1 . C o m m i t t e d C h o i c e L a n g u a g e s Historically, the Committed Choice Language approach has received considerable attention [Clark and Gregory, 1986] [Shapiro, 1986] [Ueda, 1985] . Although we do not intend to fight against this class of languages (we find it quite complementary to our own), this approach lacks at least two important features: • It is not really user-oriented: Almost all these languages (Parlog, Concurrent Prolog, KLl) suffer from a complicated semantic definition, which is reflected in the numerous existing implementations and discussions around both the languages and their implementations. Their most recent derivatives, e.g. Kernel Parlog, Flat CP and the Logix System [Silverman and Houri, 1985], or Flat GHC have reduced capabilities in order to simplify and clarify the semantics of the guards in a clause. The OR-parallelism, a very important source of useful parallelism, is somewhat difficult to handle because it is basically excluded by the principle of guards. The annotations in CP or the modes in Parlog, even if they make the writing of programs not too difficult, often lead to a painful re-reading of the program. • It is not really implementation-oriented: this approach often leads to an explosion of processes which often bring very little parallelism for very much control and synchronization overhead. It is our strong feeling thai the user must be able to control the parallelism to avoid such situations. This class of languages seems to be well adapted to some applications such as systems programming, simulation or expression of control for numerical programming, where it is useful to have some kind of synchronization mechanisms. Although different but probably aimed at the same applications is Delta Prolog [Pereira et al., 1986] in which explicit events are managed by the programmer to express the synchronization. 48 ARCHITECTURES AND LANGUAGES 2.2. " A l l s o l u t i o n s " L a n g u a g e s . By contrast, another class of languages avoids implicit or explicit synchronisation constructs, and concentrates on pure parallelism (AND-parallelism, OR-parallelism, induced parallelism). This approach has also been addressed by many people, and at different levels: automatic parallelism detection jChang and Despain, 1984], pure OR-parallel models |Ciepielewski and Hausmann, 1986) |Kumon et al., 1986), more complete systems including a language like PRISM {Kasif et al., 1983), an execution model such as P1M-D [lto and Masuda, 1984) or Argonne Labs ANLWAM [Butler et al., 1986). Among those works, only PRISM really addresses the problems from the language level to the implementation on parallel processors. 2.3. O b j e c t i v e s o f t h e P E P S y s L a n -